<HTML>
<HEAD>
<TITLE> PCK Required Reading </TITLE>
</HEAD>

<BODY style="color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">

<A NAME="top"></A>

<TABLE STYLE="text-align: left; margin-left: auto; margin-right: auto; width: 800px;" BORDER="0" CELLPADDING="5" CELLSPACING="2">
<TBODY>
<TR>
  <TD STYLE="background-color: rgb(153, 153, 153); vertical-align: middle; text-align: center;">
  <DIV ALIGN="right">
    <SMALL><SMALL><A HREF="index.html">Index Page</A></SMALL></SMALL>
  </DIV>
  <B>PCK Required Reading</B> </TD>
</TR>
<TR>
  <TD STYLE="vertical-align: top;">

<H2> Table of Contents
</H2>

<PRE>
   <A HREF="#PCK Required Reading">PCK Required Reading</A>
      <A HREF="#Abstract">Abstract</A>
         <A HREF="#Intended Audience">Intended Audience</A>
         <A HREF="#References">References</A>
      <A HREF="#Introduction">Introduction</A>
         <A HREF="#Body Codes">Body Codes</A>
         <A HREF="#Epochs and Reference Frames">Epochs and Reference Frames</A>
         <A HREF="#Planetocentric Coordinates">Planetocentric Coordinates</A>
      <A HREF="#Using the PCK System: Overview">Using the PCK System: Overview</A>
      <A HREF="#Orientation Models used by PCK Software">Orientation Models used by PCK Software</A>
   <A HREF="#The Two Formats of PCK files">The Two Formats of PCK files</A>
         <A HREF="#Detection of Non-native Text Files">Detection of Non-native Text Files</A>
         <A HREF="#DAF Run-Time Binary File Format Translation">DAF Run-Time Binary File Format Translation</A>
      <A HREF="#NAIF Text Kernel Format">NAIF Text Kernel Format</A>
      <A HREF="#Text PCK Contents">Text PCK Contents</A>
         <A HREF="#Text PCK Kernel Variable Names">Text PCK Kernel Variable Names</A>
         <A HREF="#Restrictions on the Form of Orientation Models in Text PCK Kernels">Restrictions on the Form of Orientation Models in Text PCK Kernels</A>
         <A HREF="#Models for the Sun, Planets, and Asteroids in Text PCK Kernels">Models for the Sun, Planets, and Asteroids in Text PCK Kernels</A>
         <A HREF="#Models for Satellites in Text PCK Kernels">Models for Satellites in Text PCK Kernels</A>
         <A HREF="#Epoch and Frame Specifications in Text PCK Kernels">Epoch and Frame Specifications in Text PCK Kernels</A>
         <A HREF="#Shape models in Text PCK Kernels">Shape models in Text PCK Kernels</A>
         <A HREF="#Summary of PCK Variables used in Text PCK Kernels by CSPICE">Summary of PCK Variables used in Text PCK Kernels by CSPICE</A>
      <A HREF="#Creating and Modifying Text PCKs">Creating and Modifying Text PCKs</A>
      <A HREF="#Binary PCK Kernel Format">Binary PCK Kernel Format</A>
         <A HREF="#Segments--The Fundamental PCK Building Blocks">Segments--The Fundamental PCK Building Blocks</A>
         <A HREF="#The Comment Area">The Comment Area</A>
         <A HREF="#Binary PCK Data Types">Binary PCK Data Types</A>
         <A HREF="#Supported Data Types">Supported Data Types</A>
         <A HREF="#Type 2: Chebyshev (Angles only)">Type 2: Chebyshev (Angles only)</A>
         <A HREF="#Type 3: Chebyshev (Angles and derivatives)">Type 3: Chebyshev (Angles and derivatives)</A>
      <A HREF="#Creating Binary PCKs">Creating Binary PCKs</A>
   <A HREF="#PCK Software">PCK Software</A>
      <A HREF="#Getting PCK Data into Your Program">Getting PCK Data into Your Program</A>
         <A HREF="#Loading Text PCK Kernels">Loading Text PCK Kernels</A>
         <A HREF="#Loading Binary PCK Kernels">Loading Binary PCK Kernels</A>
         <A HREF="#Unloading Binary PCK Kernels">Unloading Binary PCK Kernels</A>
      <A HREF="#Binary PCK Coverage Summary Routines">Binary PCK Coverage Summary Routines</A>
      <A HREF="#Access Routines">Access Routines</A>
         <A HREF="#High-Level PCK Data Access">High-Level PCK Data Access</A>
         <A HREF="#Low-Level PCK Data Access">Low-Level PCK Data Access</A>
      <A HREF="#Examples">Examples</A>
         <A HREF="#Transforming a body-fixed state to the inertial J2000 frame">Transforming a body-fixed state to the inertial J2000 frame</A>
      <A HREF="#Creating a binary PCK file, type 03.">Creating a binary PCK file, type 03.</A>
      <A HREF="#Summary of Calling Sequences">Summary of Calling Sequences</A>
   <A HREF="#Appendix A: Sample Text PCK file">Appendix A: Sample Text PCK file</A>

</PRE>

<HR SIZE=3 NOSHADE>

<BR><BR>
<A NAME="PCK Required Reading"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H1> PCK Required Reading
</H1><HR SIZE=3 NOSHADE><P><BR><BR><BR>
   Last revised on 2010 JUN 03 by B. V. Semenov.
<P>
 
<BR><BR>
<A NAME="Abstract"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H2> Abstract
</H2><HR ALIGN="LEFT" WIDTH=50% ><P><BR><BR>
   The Planetary Constants Kernel (PCK) subsystem provides cartographic and
   physical constants data for Solar System bodies. CSPICE software uses
   these data when determining observation geometry dependent on the size,
   shape, and orientation of planets, natural satellites, comets, and
   asteroids.
<P>
 
<BR><BR>
<A NAME="Intended Audience"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> Intended Audience
</H3><P><BR><BR>
   This document is recommended reading for all users of PCK files.
<P>
 
<BR><BR>
<A NAME="References"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> References
</H3><P><BR><BR>
   All references are to NAIF documents. The notation [Dn] refers to NAIF
   document numbers.
<P>
 
<UL>
<TT>1.</TT> [218] KERNEL Required Reading (<a href="../req/kernel.html">kernel.req</a>).
<BR><BR></UL>
<UL>
<TT>2.</TT> [219] NAIF IDS Required Reading (<a href="../req/naif_ids.html">naif_ids.req</a>).
<BR><BR></UL>
<UL>
<TT>3.</TT> [349] FRAMES Required Reading (<a href="../req/frames.html">frames.req</a>).
<BR><BR></UL>
<UL>
<TT>4.</TT> [168] SPK Required Reading (<a href="../req/spk.html">spk.req</a>).
<BR><BR></UL>
<UL>
<TT>5.</TT> [225] TIME Required Reading (<a href="../req/time.html">time.req</a>).
<BR><BR></UL>
<UL>
<TT>6.</TT> [214] ROTATIONS Required Reading (<a href="../req/rotation.html">rotation.req</a>).
<BR><BR></UL>
<UL>
<TT>7.</TT> [167] Double Precision Array Files (DAF) Required Reading (<a href="../req/daf.html">daf.req</a>).
<BR><BR></UL>
<UL>
<TT>8.</TT> [195] ``Planetary Geodetic Control Using Satellite Imaging,'' Journal of
Geophysical Research, Vol. 84, No. B3, March 10, 1979, by Thomas C.
Duxbury.
<BR><BR></UL>
<UL>
<TT>9.</TT> ``Report of the IAU/IAG Working Group on Cartographic Coordinates and
Rotational Elements of the Planets and Satellites: 2000.''
<BR><BR></UL>
<BR><BR>
<A NAME="Introduction"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H2> Introduction
</H2><HR ALIGN="LEFT" WIDTH=50% ><P><BR><BR>
   The functionality of the PCK subsystem is supplied by data files called
   ``PCK files'' (or PCKs) and by CSPICE subroutines that can read and
   interpret the data in these files.
<P>
 
   Historically, only one type of PCK existed, the text PCK file (called
   the "P_constants kernel.") These ASCII files can be easily viewed and
   modified via text editor. The current SPICE system also supports a
   binary PCK. These files contain more precise body orientation
   information in binary format, this format permits large amounts of data
   to be stored and quickly accessed. Binary PCK files exists only for the
   moon, earth, and the asteroid Eros.
<P>
 
   The purpose of the PCK and associated software is to provide SPICE users
   a convenient mechanism for supplying planetary physical constants to
   application programs. CSPICE software reads files conforming to these
   formats and returns both the data contained in such files and a few
   commonly used numeric quantities derived from the kernel data.
<P>
 
<BR><BR>
<A NAME="Body Codes"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> Body Codes
</H3><P><BR><BR>
   NAIF software uses a system of integer codes to conveniently represent
   both celestial bodies and spacecraft. The document ``NAIF IDS Required
   Reading'', <a href="../req/naif_ids.html">naif_ids.req</a>, [219] describes this system in detail.
<P>
 
   In this document, the following features of the code system will be
   relied on:
<P>
 
<UL>
<TT>--</TT> The code for the barycenter of the nth planetary system is n. The count
starts at 1, which stands for Mercury. (The code for the Sun is 10.)
<BR><BR></UL>
<UL>
<TT>--</TT> The code for the nth planet's barycenter is n; e.g., the code for Jupiter's
barycenter is 5.
<BR><BR></UL>
<UL>
<TT>--</TT> The code for the nth planet's mass center is n99; e.g, the code for the
Earth is 399.
<BR><BR></UL>
<UL>
<TT>--</TT> Natural satellites have ID codes of the form
<BR><BR></UL>
<PRE>
              PNN, where
 
                     P  is  1, ..., 9
                 and NN is 01, ... 98
</PRE>
<UL>
<TT>&#32;&#32;</TT> or
<BR><BR></UL>
<PRE>
              PXNNN, where
 
                     P   is    1, ...,  9,
                     X   is    0  or    5,
                 and NNN is  001, ... 999
 
              Codes with X = 5 are provisional.
</PRE>
<UL>
<TT>&#32;&#32;</TT> For example, the code for the Earth's moon is 301, and the code for the
Ganymede is 503.
<BR><BR></UL>
<BR><BR>
<A NAME="Epochs and Reference Frames"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> Epochs and Reference Frames
</H3><P><BR><BR>
   Some constants that frequently appear in PCK files are associated with a
   particular epoch and with a particular reference frame. For example, PCK
   files released by NAIF typically contain constants that define the axes
   of various body-fixed planetocentric coordinate systems, given relative
   to a specified inertial reference frame, as a function of time. In this
   sort of definition, the independent variable, time, is measured relative
   to a specified reference epoch.
<P>
 
   Typical choices of reference frames associated with PCK constants would
   be J2000 or B1950. Typical choices of reference epochs would be the
   J2000 epoch (JED 24515145.0) or the J1950 epoch (JED 2433282.5).
<P>
 
   Within CSPICE, reference frames are usually indicated by short character
   strings, such as 'J2000'. The names of the body-fixed reference frames
   are usually constructed by adding the prefix ``IAU_'' to the name of the
   body, for example ``IAU_MARS'' for Mars. The exception from this rule
   are body-fixed reference frames associated with high-precision
   orientation provided in binary PCK files. For more details see FRAMES
   Required Reading, <a href="../req/frames.html">frames.req</a>.
<P>
 
   However, CSPICE also has a system of integer codes used by some routines
   to name reference frames. This coding system is described in detail in
   <a href="../req/frames.html">frames.req</a>. An example of the correspondence of codes and names is shown
   below:
<P>
 
<PRE>
   Code    Name       Description
   -----   --------   -------------------------------------------
     1     J2000      Earth mean equator, dynamical equinox of J2000
     2     B1950      Earth mean equator, dynamical equinox of B1950
</PRE>
<BR><BR>
<A NAME="Planetocentric Coordinates"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> Planetocentric Coordinates
</H3><P><BR><BR>
   The body-fixed ``Planetocentric'' coordinate system referred to in this
   document is defined for solar system bodies as follows:
<P>
 
<UL>
<TT>--</TT> The x-axis of the Planetocentric coordinate system for a specified body
lies both in the body's equatorial plane and in the plane containing the
body's prime meridian.
<BR><BR></UL>
<UL>
<TT>--</TT> The z-axis is parallel to the body's mean axis of rotation and points North
of the invariable plane of the solar system (regardless of the body's spin
direction). The north pole is the pole of rotation.
<BR><BR></UL>
<UL>
<TT>--</TT> The y-axis is defined as the cross product of the z and x axes, in that
order. Thus, the frame is right-handed.
<BR><BR></UL>
   The above definition implies that the axes of a planetocentric system
   are time-varying. Thus a complete specification of the axes requires
   identification of an epoch as well as the body.
<P>
 
<BR><BR>
<A NAME="Using the PCK System: Overview"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H2> Using the PCK System: Overview
</H2><HR ALIGN="LEFT" WIDTH=50% ><P><BR><BR>
   This section describes how PCK files and software are used in
   application programs.
<P>
 
   The use of PCK data in an application program requires three steps:
<P>
 
<UL>
<TT>1.</TT> Selecting the appropriate PCK file(s) for the problem.
<BR><BR></UL>
<UL>
<TT>2.</TT> Reading the PCK data into the program.
<BR><BR></UL>
<UL>
<TT>3.</TT> Using the data within the program.
<BR><BR></UL>
   Step 1 is not necessarily trivial since there may be no single set of
   ``best values'' for physical constants of interest; the ``best'' values
   - if such exist - depend on the problem. The user's judgment, supported
   by comments and usage notes in the PCK file, is required for this step.
<P>
 
   Step 2 is referred to as ``loading'' a PCK file. Text PCK files are
   loaded by calling the CSPICE subroutine <a href="../cspice/furnsh_c.html">furnsh_c</a> and supplying the name
   of the PCK file to load as the input argument. All of the data in a text
   PCK file is read into memory when the file is loaded by an application
   program at run-time. Binary PCK files are also loaded by calling the
   CSPICE subroutine <a href="../cspice/furnsh_c.html">furnsh_c</a>. This data will be accessible throughout the
   rest of the program run, unless it is deliberately overwritten or
   unloaded. Multiple text and multiple binary PCKs can be used
   simultaneously.
<P>
 
   The data available from binary PCKs take precedence over that from text
   PCKs. If data for a requested planetary constant and time period is
   covered by a loaded binary PCK file, the subsystem returns and uses the
   binary data. If multiple binary PCK files are loaded, the most recently
   loaded file takes precedence, down to the binary file loaded earliest.
   The subsystem defaults to text PCK data when no binary PCK data is
   available. If the user loaded multiple text PCKs, and those PCKs
   contained variable assignments using the same variable name, the later
   loads overwrite the assignments defined by earlier loads.
<P>
 
   Step 3, accessing loaded PCK data, is accomplished via calls to CSPICE
   routines. At the lowest level, these access routines allow the calling
   program to retrieve specified data that has been read from one or more
   PCK files. Higher-level access routines can return quantities derived
   from PCK data that has been loaded; the most commonly used such quantity
   is a matrix that transforms state vectors or position vectors between
   inertial and body-fixed planetocentric coordinates. The CSPICE
   subroutines <a href="../cspice/sxform_c.html">sxform_c</a> and <a href="../cspice/pxform_c.html">pxform_c</a> can calculate this transformation. The
   names of the body-fixed reference frames used as inputs to these
   routines are usually constructed by adding the prefix ``IAU_'' to the
   name of the body, for example ``IAU_MARS'' for Mars (for more details
   see FRAMES Required Reading, <a href="../req/frames.html">frames.req</a>). The subroutine <a href="../cspice/bodvrd_c.html">bodvrd_c</a>
   retrieves information on body orientation and body shape.
<P>
 
   For text PCK files, the PCK software can be thought of as ``buffering''
   all data loaded from PCK files: the data from these files is retained in
   memory. Therefore, repeated calls to the PCK access routines do not
   incur the inefficiency of re-reading data from files. For binary PCK
   file, like the case of the SPK and CK readers, only a portion of the
   most recently used information is buffered.
<P>
 
   The data structure used by CSPICE to maintain associations of text
   kernel variable names and values is called the ``kernel pool.'' Data
   loaded into memory via <a href="../cspice/furnsh_c.html">furnsh_c</a> is referred to as ``being present in the
   kernel pool.'' There is no analog to the kernel pool for binary PCK
   files.
<P>
 
<BR><BR>
<A NAME="Orientation Models used by PCK Software"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H2> Orientation Models used by PCK Software
</H2><HR ALIGN="LEFT" WIDTH=50% ><P><BR><BR>
   The orientation models used by CSPICE PCK access routines all express
   the direction of the pole and location of the prime meridian of a body
   with respect to an inertial reference frame, as a function of time. This
   information defines the coordinate axes of the ``Body Equator and Prime
   Meridian'' system.
<P>
 
   The orientation models use three Euler angles to describe the pole and
   prime meridian location: the first two angles, in order, are the right
   ascension and declination (henceforth RA and DEC) of the north pole of a
   body as a function of time. The third angle is the prime meridian
   location (represented by `W'), which is expressed as a rotation about
   the north pole, also a function of time. The coordinate transformation
   defined by the Euler angles is represented by the matrix product
<P>
 
<PRE>
   [ W ]    [ Pi/2 - Dec ]    [ Pi/2 + RA ]
        3                 1                3
</PRE>
   where
<P>
 
<PRE>
   [ W ]
        i
</PRE>
   denotes the matrix that rotates vectors by -W about the ith coordinate
   axis, using the right hand rule. (This notation is explained in detail
   in <a href="../req/rotation.html">rotation.req</a>).
<P>
 
   In PCK files, the time arguments of functions that define orientation
   always refer to Barycentric Dynamical Time (TDB), measured in centuries
   or days past a specified epoch such as J2000, which is Julian ephemeris
   date 2451545.0. The time units expected by the CSPICE software are
   ephemeris days for prime meridian motion and ephemeris centuries for
   motion of the pole.
<P>
 
<BR><BR>
<A NAME="The Two Formats of PCK files"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H1> The Two Formats of PCK files
</H1><HR SIZE=3 NOSHADE><P><BR><BR><BR>
   There are two general forms for PCK files, text and binary files. Text
   files are ASCII and can be created and modified with an editor.
   Therefore, they are easily changed and read. Binary files are created
   via CSPICE programs and have a particular format and architecture. They
   cannot be examined or changed with an editor. These files require CSPICE
   software for their manipulation. Binary files can contain more data and
   are faster to use. In the PCK case, the binary files contain higher
   precision data than the text files.
<P>
 
<BR><BR>
<A NAME="Detection of Non-native Text Files"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> Detection of Non-native Text Files
</H3><P><BR><BR>
   The various platforms supported by CSPICE use different end-of-line
   (EOL) indicators in text files:
<P>
 
<PRE>
 
   Environment                  Native End-Of-Line
                                Indicator
   ___________                  _____________________
 
   PC DOS/Windows                &lt;CR&gt;&lt;LF&gt;
   Unix                          &lt;LF&gt;
   Linux                         &lt;LF&gt;
   Alpha  Digital Unix           &lt;LF&gt;
   Mac OS X                      &lt;LF&gt;
   Macintosh Classic (OS9)       &lt;CR&gt;
 
</PRE>
   As of CSPICE N0059, the CSPICE text kernel loaders, <a href="../cspice/furnsh_c.html">furnsh_c</a> and
   <a href="../cspice/ldpool_c.html">ldpool_c</a>, can read and parse non-native text files. The FORTRAN SPICELIB
   does not include this capability.
<P>
 
   Please be aware the CSPICE text file reader, <a href="../cspice/rdtext_c.html">rdtext_c</a>, does not possess
   the capability to read non-native text files.
<P>
 
<BR><BR>
<A NAME="DAF Run-Time Binary File Format Translation"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> DAF Run-Time Binary File Format Translation
</H3><P><BR><BR>
   As of the CSPICE N0052 release (January, 2002), certain supported
   platforms are able to read DAF-based binary files (SPK, CK and binary
   PCK) written in a non-native, binary representation. This access is
   read-only; any operations requiring writing to the file (adding
   information to the comment area, or appending additional ephemeris data,
   for example) require prior conversion of the file to the native binary
   file format. See the Convert User's Guide, <a href="../ug/convert.html">convert.ug</a>, for details.
<P>
 
<BR><BR>
<A NAME="NAIF Text Kernel Format"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H2> NAIF Text Kernel Format
</H2><HR ALIGN="LEFT" WIDTH=50% ><P><BR><BR>
   Text PCK files express data as ``assignments''; in text PCKs, values are
   associated with name strings using a ``keyword = value'' format. These
   name strings, together with their associated values, are called ``kernel
   variables.'' The CSPICE routines that access text PCK data at run time
   use these associations established by loaded text PCK files to reference
   desired data values; these routines look up data ``by name.'' Therefore,
   programmers writing applications that use text PCKs must coordinate use
   of kernel variable names between their software and the text PCK files
   used by their software.
<P>
 
   Text PCK files conform to a flexible format called ``NAIF text kernel''
   format. The SPICE file identification word provided by itself on the
   first line of the text PCK file is ``KPL/PCK''. Both the NAIF text
   kernel format and SPICE file identification word are described in detail
   in the Kernel Required Reading document, <a href="../req/kernel.html">kernel.req</a>. For the reader's
   convenience, an overview of the NAIF text kernel format is provided
   here.
<P>
 
   NAIF text kernels are, first of all, ASCII files. As such, they are
   human readable and can be easily modified by text editors. In addition,
   NAIF text kernels can be readily ported between computer systems, even
   when the systems in question have different file systems and file
   formats.
<P>
 
   The NAIF text kernel format provides for representation of data in a
   ``keyword = value'' syntax. The format also provides for the inclusion
   of free-form comment blocks.
<P>
 
   There are two kinds of data that can be placed in NAIF text kernel
   files: double precision numbers and UTC time strings.
<P>
 
   According to the text kernel format, a text kernel nominally consists of
   a series of sets of contiguous lines (or ``blocks'') of comments,
   alternating with blocks of data. Comment blocks are started with the
   string (called a ``control sequence'')
<P>
 
<PRE>
   \begintext
</PRE>
   alone on a line, as shown here. Comment blocks are ended by the control
   sequence
<P>
 
<PRE>
   \begindata
</PRE>
   alone on a line. In a text kernel file, the lines preceding the first
<P>
 
<PRE>
   \begindata
</PRE>
   control sequence are considered to constitute a comment block; the
<P>
 
<PRE>
   \begintext
</PRE>
   control sequence is optional for this comment block.
<P>
 
   Comment blocks can contain arbitrary text, except for non-printing
   characters or lines that can be interpreted as control sequences. On the
   other hand, data must be organized according to a very specific format:
   all of the data in a text kernel must appear in the form of an
   ``assignment'' such as
<P>
 
<PRE>
   NAME = ( VALUE1, VALUE2, ... )
</PRE>
   where name is a string no longer than 32 characters, and the values on
   the right hand side are double precision numbers. A specific example is
   shown below:
<P>
 
<PRE>
   BODY399_RADII     = (  6378.140  6378.140  6356.75  )
</PRE>
   Some variations on the form shown here are allowed: commas between data
   values are optional, the right hand side of the assignment can be
   continued over multiple lines, and the numbers can be expressed as
   integers or reals without causing the PCK software to fail. Assignments
   of scalars do not require the value on the right hand side to be
   enclosed in parentheses, but that notation is frequently used as a
   visual cue. Blank lines within or between assignments are ignored by the
   CSPICE software that reads text kernels.
<P>
 
   In addition to numbers, UTC strings can be assigned to variables. The
   ``@'' character is used to identify the strings as time strings. The
   strings are stored internally as double precision numbers representing
   ``UTC seconds past J2000.'' An example is the assignment:
<P>
 
<PRE>
   SCLK_KERNEL_ID            = ( @01-MAY-1991/16:25 )
</PRE>
   See <a href="../req/kernel.html">kernel.req</a> for a complete discussion of the allowed form of
   assignments.
<P>
 
   The effect of an assignment in a text PCK file is to associate values
   with a name. The name is referred to as a ``kernel variable.'' When a
   text PCK file is loaded by an application, the associations of names and
   values established by the PCK are maintained: the values associated with
   a given name can be retrieved at any time.
<P>
 
<BR><BR>
<A NAME="Text PCK Contents"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H2> Text PCK Contents
</H2><HR ALIGN="LEFT" WIDTH=50% ><P><BR><BR>
   Other than the limitations imposed by the PCK file formats, no absolute
   restrictions exist on the names or values of the variables used in PCK
   files. However, the CSPICE kernel concept calls for the contents of PCK
   files to be limited to physical and cartographic constants describing
   extended solar system bodies: radii of bodies, constants defining
   orientation models, masses or values of GM are examples of data
   appropriate for inclusion in PCKs.
<P>
 
   CSPICE includes a set of routines (<a href="../cspice/gipool_c.html">gipool_c</a>, <a href="../cspice/gdpool_c.html">gdpool_c</a>, gipool_c) for
   general access to text PCK defined data. Another set (<a href="../cspice/bodvrd_c.html">bodvrd_c</a>,
   <a href="../cspice/bodvcd_c.html">bodvcd_c</a>, sxform_c, <a href="../cspice/pxform_c.html">pxform_c</a>) recognizes and uses particular PCK data to
   return body constants or the matrices to transform position or state
   vectors between reference frames.
<P>
 
   In this document, the formulas defining time-varying coordinate
   transformation matrices and Euler angles are referred to as
   ``orientation models'' since they define the orientation of an extended
   body with respect to specific inertial frames.
<P>
 
   Because PCK access routines that deal with orientation models are used
   extensively in CSPICE and applications that use the Toolkit, the kernel
   variables that these routines rely on will be discussed in detail.
<P>
 
   Those functions defining the Euler angles are characterized by a set of
   parameters. The specific values of the parameters are values assigned to
   kernel variables in PCK files. The functions themselves are implemented
   by code within CSPICE routines. The general form of the functions is
   that used in the IAU/IAG 2000 report. Values shown in this document
   reflect the 2000 report. For the latest PCK values, check with NAIF.
<P>
 
   In a text PCK file, the variables (Euler angles)
<P>
 
<PRE>
   RA,  DEC,  W
</PRE>
   for the Earth are represented by the names
<P>
 
<PRE>
   BODY399_POLE_RA
   BODY399_POLE_DEC
   BODY399_POLE_PM
</PRE>
   The equations above are expressed in a text PCK file by the kernel
   variable assignments (Values taken from IAU/IAG 2000 report.)
<P>
 
<PRE>
   BODY399_POLE_RA        = (    0.      -0.641         0. )
   BODY399_POLE_DEC       = (  +90.      -0.557         0. )
   BODY399_PM             = (  190.16  +360.9856235     0. )
</PRE>
   Note that the string ``PM'' is used in place of ``W'' for the kernel
   variable associated with the prime meridian.
<P>
 
   If you examine a PCK file produced by NAIF, you'll see an additional
   symbol grouped with the ones listed here; it is
<P>
 
<PRE>
   BODY399_LONG_AXIS
</PRE>
   This term is currently zero for all bodies except Mars. It represents
   the offset between the longest axis of the triaxial ellipsoid used to
   model a body and the prime meridian of the body.
<P>
 
<BR><BR>
<A NAME="Text PCK Kernel Variable Names"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> Text PCK Kernel Variable Names
</H3><P><BR><BR>
   Text PCK variables recognized by CSPICE PCK access routines have names
   that follow a simple pattern: variables related to a body whose NAIF
   integer code is nnn have names of the form
<P>
 
<PRE>
   BODYnnn_&lt;item name&gt;
</PRE>
   where
<P>
 
<PRE>
   &lt;item name&gt;
</PRE>
   is a short string that identifies the type of quantity the kernel
   variable represents. For example, the variable containing quadratic
   polynomial coefficients for the right ascension of the Earth's north
   pole is
<P>
 
<PRE>
   BODY399_POLE_RA
</PRE>
   Note the number ``399'' appearing in the kernel variable names; this is
   the NAIF integer code for the Earth.
<P>
 
   The following sections specify the specific item names recognized by PCK
   access routines.
<P>
 
<BR><BR>
<A NAME="Restrictions on the Form of Orientation Models in Text PCK Kernels"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> Restrictions on the Form of Orientation Models in Text PCK Kernels
</H3><P><BR><BR>
   Orientation models usable by CSPICE's text PCK access routines are not
   available for all solar system bodies. For example, Saturn's moon
   Hyperion is ``tumbling'' and does not admit a description of its motion
   by the sort of models used in text PCKs.
<P>
 
   To date, no PCK files containing models for the rotation of comets have
   been produced or collected by NAIF. Models for the rotation of comets,
   as well as for the rotation of asteroids and the natural satellites of
   planets, can be accommodated by the PCK system only if the models have
   the form described in the section ``Models for the Sun, Planets, and
   Asteroids'' or in ``Models for Satellites'' or if binary PCK data is
   available.
<P>
 
<BR><BR>
<A NAME="Models for the Sun, Planets, and Asteroids in Text PCK Kernels"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> Models for the Sun, Planets, and Asteroids in Text PCK Kernels
</H3><P><BR><BR>
   For the Sun, planets, and asteroids, the expressions used in text PCK
   files for the north pole direction and prime meridian location are
   always quadratic polynomials, where the independent variable is time.
   Some coefficients may be zero.
<P>
 
   Let RA and DEC represent the right ascension and declination of a body's
   north pole, and let W be the prime meridian location, measured in the
   counterclockwise direction, from the cross product of the Earth's
   ``mean'' North pole at the J2000 epoch (as used in defining the J2000
   frame) and BODY's North pole at et, to BODY's prime meridian at et.
<P>
 
   The variables RA, DEC, and W constitute sufficient information to
   compute the transformation from a specified inertial frame to
   body-fixed, planetocentric coordinates for the body to which they apply,
   at a specified time.
<P>
 
   The angles RA, DEC, and W are defined as follows:
<P>
 
<PRE>
                                   2
                              RA2*t
   RA  =  RA0  +  RA1*t/T  +  ------
                                 2
                                T
 
                                    2
                              DEC2*t
   DEC =  DEC0 + DEC1*t/T  +  -------
                                 2
                                T
 
                                  2
                              W2*t
   W   =  W0   + W1*t/d    +  -----
                                 2
                                d
 
</PRE>
   where
<P>
 
<PRE>
   d = seconds/day
   T = seconds/Julian century
   t = ephemeris time, expressed as seconds past the reference epoch
       for this body or planetary system
</PRE>
   Below is an example showing actual values of the parameters used to
   define the latest IAU model for orientation of the Earth. Here, the
   motions of both the pole and the prime meridian are given by linear
   polynomials; the quadratic terms are all zero. The values shown here are
   taken from the IAU/IAG 2000 report. In that document, the names
<P>
 
<PRE>
   alpha
        0
</PRE>
   and
<P>
 
<PRE>
   delta
        0
</PRE>
   are used in place of the names RA and DEC used here.
<P>
 
<PRE>
   alpha   =   0.00 - 0.641 T
        0
 
   delta   =  90.0  - 0.557 T
        0
 
   W       =  190.16 + 360.9856235 d
 
   T represents centuries past J2000 (TDB),
 
   d represents days past J2000 (TDB).
</PRE>
<BR><BR>
<A NAME="Models for Satellites in Text PCK Kernels"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> Models for Satellites in Text PCK Kernels
</H3><P><BR><BR>
   Orientation models for natural satellites of planets are a little more
   complicated; in addition to polynomial terms, the RA, DEC, and W
   expressions include trigonometric terms. The arguments of the
   trigonometric terms are linear polynomials. These arguments are usually
   called ``phase angles.'' However, within CSPICE internal documentation,
   these quantities are called ``nutation precession angles''; for
   consistency with the CSPICE software, we'll use this terminology in the
   following discussion.
<P>
 
   Expressions for the right ascension and declination of the north pole
   and the location of the prime meridian for any satellite of a given
   planet are as follows:
<P>
 
<PRE>
                                2      ____
                           RA2*t       \
   RA  = RA0  + RA1*t/T  + ------   +  /     a  sin theta
                              2        ----   i          i
                             T           i
 
                                 2     ____
                           DEC2*t      \
   DEC = DEC0 + DEC1*t/T + -------  +  /    d  cos theta
                               2       ----  i          i
                              T          i
 
                               2       ____
                           W2*t        \
   W   = W0   + W1*t/d   + -----    +  /     w  sin theta
                              2        ----   i          i
                             d           i
</PRE>
   where
<P>
 
<PRE>
   d = seconds/day
   T = seconds/Julian century
   t = ephemeris time, expressed as seconds past a reference epoch
</PRE>
   RA0, RA1, DEC0, DEC1, W0, and W1 are constants specific to each
   satellite.
<P>
 
   The nutation precession angles
<P>
 
<PRE>
   theta
        i
</PRE>
   are specific to each planet. The coefficients
<P>
 
<PRE>
   a ,  d ,  and w
    i    i        i
</PRE>
   are specific to each satellite.
<P>
 
   As an example, the nutation precession angles for Earth given by [252]
   are shown below. That document uses the variable names E1---E5 in place
   of
<P>
 
<PRE>
   theta  --- theta
        1          5
</PRE>
   in the equations above.
<P>
 
<PRE>
   E1 = 125.045 -  0.052992 d
   E2 = 250.090 -  0.105984 d
   E3 = 260.008 + 13.012001 d
   E4 = 176.625 + 13.340716 d
   E5 = 357.529 +  0.985600 d
 
   Here d represents days past J2000 (TDB)
</PRE>
   Because the NAIF Toolkit software expects the time units for the angles
   to be centuries (as in the IAU models for most bodies---the Earth is an
   exception), the linear coefficients are scaled by 36525.0 for use in the
   kernel variable assignments:
<P>
 
<PRE>
   BODY3_NUT_PREC_ANGLES  = (  125.045    -1935.5328
                               250.090    -3871.0656
                               260.008   475263.3
                               176.625   487269.6519
                               357.529    35999.04     )
</PRE>
   In this assignment, the constant and linear polynomial coefficients for
   each nutation precession angle are listed together: the numbers 125.045
   and -1935.5328 are the constant and linear terms for the angle ``E1,''
   and so on.
<P>
 
   Note the body number 3 in the kernel variable name above; this number
   designates the Earth-Moon barycenter. The PCK access routines expect
   nutation precession angles to be associated with the barycenters of
   planetary systems.
<P>
 
   Here are the expressions for the right ascension and declination of the
   moon, also taken from [252]:
<P>
 
<PRE>
   alpha   =  270.000 +  0.003 T -  3.878 sin(E1)  -  0.120 sin(E2)
        0
                          +  0.070 sin(E3)  -  0.017 sin(E4)
 
 
   delta   =  66.541  + 0.013 T  +  1.543 cos(E1)  +  0.024 cos(E2)
        0
                       -  0.028 cos(E3)  +  0.007 cos(E4)
 
 
   W       =  38.317   + 13.1763582 d    +  3.558 sin(E1)
 
                       +  0.121 sin(E2)
 
                       -  0.064 sin(E3)
 
                       +  0.016 sin(E4)
 
                       +  0.025 sin(E5)
 
   Here d represents days past J2000 (TDB),
   and T represents Julian centuries past J2000 (TDB).
   E1--E5 are the nutation precession angles.
</PRE>
   The polynomial terms are assigned to symbols by the statements
<P>
 
<PRE>
   BODY301_POLE_RA        = (  270.000    0.003        0. )
   BODY301_POLE_DEC       = (  +66.541    0.013        0. )
   BODY301_PM             = (   38.317  +13.1763582    0. )
</PRE>
   The coefficients of the trigonometric terms are assigned to symbols by
   the statements
<P>
 
<PRE>
   BODY301_NUT_PREC_RA  = (  -3.878  -0.120  +0.070  -0.017   0.    )
   BODY301_NUT_PREC_DEC = (  +1.543  +0.024  -0.028  +0.007   0.    )
   BODY301_NUT_PREC_PM  = (  +3.558  +0.121  -0.064  +0.016  +0.025 )
</PRE>
   Note that for the RA and PM (prime meridian) assignments, the ith term
   is the coefficient of sin(Ei) in the expression used in the IAU model,
   while for the DEC assignment, the ith term is the coefficient of cos(Ei)
   in the expression used in the IAU model.
<P>
 
   CSPICE software for text PCKs expects the models for satellite
   orientation to follow the form of the model shown here: the polynomial
   terms in the RA, DEC, and W expressions are expected to be quadratic,
   the trigonometric terms for RA and W (satellite prime meridian) are
   expected to be sums of sines of nutation precession angles, and the
   trigonometric terms for DEC are expected to be sums of cosines of
   nutation precession angles. The nutation precession angles themselves
   are defined by linear polynomial functions of time.
<P>
 
   Note that the number of values defining the nutation precession angles
   for a planetary system must be consistent with the number of
   trigonometric terms used in the expressions for the RA, DEC and W angles
   for the satellites of that system. See ``Creating and Modifying Text
   PCKs Kernels'' for details.
<P>
 
<BR><BR>
<A NAME="Epoch and Frame Specifications in Text PCK Kernels"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> Epoch and Frame Specifications in Text PCK Kernels
</H3><P><BR><BR>
   The constants used in PCK files to define an orientation model for a
   specified body are assumed by default to define a time-dependent
   rotation R(t) that converts vectors from J2000 coordinates to
   body-fixed, planetocentric coordinates at the epoch t seconds past
   J2000, TDB (JED 2451545.0). We say that the constants are ``referenced
   to the J2000 epoch and J2000 frame.'' However, these default values for
   the epoch and frame of the constants may be overridden: it is possible
   to use constants referenced to the B1950 frame and to the J1950 epoch,
   for example.
<P>
 
   The default constants and frame for a body are overridden by setting the
   values of the kernel variables
<P>
 
<PRE>
   BODY&lt;id code&gt;_CONSTANTS_REF_FRAME
</PRE>
   and
<P>
 
<PRE>
   BODY&lt;id code&gt;_CONSTANTS_JED_EPOCH
</PRE>
   Here
<P>
 
<PRE>
   &lt;id code&gt;
</PRE>
   is:
<P>
 
<UL>
<TT>--</TT> for planets and their satellites: the NAIF integer code of the
corresponding planetary system's barycenter.
<BR><BR></UL>
<UL>
<TT>--</TT> for other bodies: the NAIF integer code of the body itself.
<BR><BR></UL>
   The values of the frame specifier variable
<P>
 
<PRE>
   BODY&lt;id code&gt;_CONSTANTS_REF_FRAME
</PRE>
   are the codes returned by the CSPICE routine IRFNUM. Some of the
   commonly used codes and the corresponding frames are:
<P>
 
<PRE>
   Code        Frame
   ----        -----
     1         J2000
 
     2         B1950
 
     3         FK4 (used in CSPICE for `EME50')
</PRE>
   For example, to use constants referenced to the FK4 or EME50 frame for
   the asteroid Gaspra (ID code = 9511010), the PCK file containing the
   constants should include the assignment
<P>
 
<PRE>
   BODY9511010_CONSTANTS_REF_FRAME   =   (  3  )
</PRE>
   The values of the epoch specifier variable
<P>
 
<PRE>
   BODY&lt;id code&gt;_CONSTANTS_JED_EPOCH
</PRE>
   are Julian ephemeris dates. To use constants for Gaspra referenced to
   the J1950 epoch, the PCK file containing the constants should include
   the assignment
<P>
 
<PRE>
   BODY9511010_CONSTANTS_JED_EPOCH   =   (  2433282.5D0 )
</PRE>
   The creator of a PCK file can set the frame and epoch of the constants
   on a body-by-body basis, except in the case of planets and their
   (natural) satellites, where a single choice of frame and epoch must be
   used for each planetary system. For example, to use constants referenced
   to the B1950 frame and J1950 epoch for the Earth and Moon, you would
   make the assignments
<P>
 
<PRE>
   BODY3_CONSTANTS_REF_FRAME   =   (  2           )
   BODY3_CONSTANTS_JED_EPOCH   =   (  2433282.5D0 )
</PRE>
   The ID code `3' designates the Earth-Moon barycenter.
<P>
 
   Note: the assignment
<P>
 
<PRE>
   BODY399_CONSTANTS_REF_FRAME   =   (  2           )
   BODY399_CONSTANTS_JED_EPOCH   =   (  2433282.5D0 )
</PRE>
   would be ignored by the PCK reader routines; you cannot assign a frame
   or epoch using the ID code of a planet or satellite.
<P>
 
   Using constants referenced to frames or epochs other than J2000 does not
   affect the definitions of the inputs or outputs of any of the PCK access
   routines. These routines make the necessary transformations internally
   to take into account the reference frame and epoch of the orientation
   constants in the kernel pool. Thus the PCK access routine <a href="../cspice/sxform_c.html">sxform_c</a>,
   which has the argument list
<P>
 
<PRE>
   <a href="../cspice/sxform_c.html">sxform_c</a> ( from, to, et, rotate )
</PRE>
   returns the transformation matrix mapping state vectors frame ```from'''
   into frame ```to''' for ephemeris time expressed as ```et''' seconds
   past the J2000 epoch (JED 2451545.0), regardless of the epoch or frame
   of the orientation constants used to compute ```rotate'.''
<P>
 
<BR><BR>
<A NAME="Shape models in Text PCK Kernels"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> Shape models in Text PCK Kernels
</H3><P><BR><BR>
   CSPICE contains a number of geometry routines that make use of triaxial
   ellipsoidal models of extended solar system bodies. Although CSPICE
   currently contains no routines that directly use the specific PCK
   variables that define these models, text PCK files typically contain
   radii of solar system bodies, since these values can be looked up by
   low-level text PCK access routines and subsequently used by CSPICE
   geometry routines.
<P>
 
   In text PCK files produced by NAIF, the radius values for body nnn are
   assigned to the variable
<P>
 
<PRE>
   BODYnnn_RADII
</PRE>
   Three radius values are always assigned for each instance of this
   variable. The data are ordered as in the IAU/IAG 2000 report: the
   equatorial radii are listed with the largest axis, often called the
   ``a'' axis, appearing first; the polar radius is last. Spheroids and
   spheres are obtained when two or all three radii are equal.
<P>
 
   Example: Radii of the Earth.
<P>
 
<PRE>
   BODY399_RADII     = (     6378.140    6378.140     6356.75   )
</PRE>
<BR><BR>
<A NAME="Summary of PCK Variables used in Text PCK Kernels by CSPICE"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> Summary of PCK Variables used in Text PCK Kernels by CSPICE
</H3><P><BR><BR>
   In order to compute transformations for the Sun, a planet, or an
   asteroid (say body number ppp), the PCK access routines require that one
   or more PCK files containing values for the following variables be
   loaded:
<P>
 
<PRE>
   BODYppp_POLE_RA
   BODYppp_POLE_DEC
   BODYppp_PM
</PRE>
   For a satellite (say body number sss), one or more PCK files containing
   values for the following variables must be loaded:
<P>
 
<PRE>
   BODYsss_POLE_RA
   BODYsss_POLE_DEC
   BODYsss_PM
   BODYsss_NUT_PREC_RA
   BODYsss_NUT_PREC_DEC
   BODYsss_NUT_PREC_PM
   BODYbbb_NUT_PREC_ANGLES
</PRE>
   where the code bbb embedded in the last name above is that of the
   barycenter of the planetary system to which the satellite belongs.
<P>
 
   The triaxial ellipsoidal model for body nnn is expressed by the
   assignment
<P>
 
<PRE>
   BODYnnn_RADII = ( &lt;larger equatorial radius&gt;,
                     &lt;smaller  equatorial radius&gt;,
                     &lt;polar radius&gt; )
</PRE>
<BR><BR>
<A NAME="Creating and Modifying Text PCKs"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H2> Creating and Modifying Text PCKs
</H2><HR ALIGN="LEFT" WIDTH=50% ><P><BR><BR>
   The PCK file text format allows NAIF Toolkit users to easily modify
   existing text PCKs and to create their own files containing values of
   their choosing. Any text editor capable of working with ASCII files can
   be used to edit text PCK files.
<P>
 
   Although the text PCK format makes it easy to modify text PCK files,
   NAIF recommends that application programmers avoid software designs that
   call for special-purpose, user-created text PCK files. The opportunities
   for confusion and errors increase with the number of available versions
   of a text PCK file (or any data file).
<P>
 
   NAIF recommends that you take the following precautions when modifying a
   text PCK file:
<P>
 
<UL>
<TT>--</TT> Change the name of the updated file.
<BR><BR></UL>
<UL>
<TT>--</TT> Document the changes by adding appropriate comments to the file. Each text
PCK file should contain sufficient information to allow a human reader to
find out who was responsible for creating the current version of the file
and what the source was for each data value in the file. If the file is an
update, the reason for the update and a summary of the differences from the
previous version should be included.
<BR><BR></UL>
<UL>
<TT>--</TT> Test the file using software that makes use of any values that you've added
or modified.
<BR><BR></UL>
   The reasons why a NAIF Toolkit user might wish to modify an existing
   text PCK are:
<P>
 
<UL>
<TT>--</TT> Removing unneeded data or comments to speed up loading and simplify the
file. Removal of data is much more important than removal of comments, as
far as speeding up kernel loading is concerned.
<BR><BR></UL>
<UL>
<TT>--</TT> Adding data values for new bodies.
<BR><BR></UL>
<UL>
<TT>--</TT> Updating existing data values or substituting preferred data values.
<BR><BR></UL>
   New kernel variables added to text PCK files should follow the naming
   conventions described in the ``Kernel Variable Names'' section. All text
   PCK variable names, whether or not they are recognized by CSPICE
   software, should start with the prefix
<P>
 
<PRE>
   BODYnnn_
</PRE>
   where nnn is the NAIF integer code of the body the variable applies to.
<P>
 
   Kernel variables having names recognized by users' application software
   are a potential problem area: if the names used in the application don't
   match those in the text PCK file, the application will fail to obtain
   the data as intended. The most frequent cause of this type of failure is
   misspelling of variable names, but programmers who considering changing
   the names of PCK variables already in use should also keep this problem
   in mind.
<P>
 
   Modifying orientation models for satellites requires attention to the
   consistency between the number of nutation precession angles and the
   number of coefficients of trigonometric functions having the nutation
   precession angles as arguments. For any planetary system, there should
   be twice as many values for the nutation precession angles as the
   maximum number of trigonometric terms in the expressions for prime
   meridian location or right ascension or declination of the pole of any
   satellite in the system. This is because the nutation precession angles
   are defined by linear polynomials; each polynomial has two defining
   coefficients.
<P>
 
   For example, the 1991 IAU model for the Earth-Moon system uses the
   following values to determine the Moon's orientation:
<P>
 
<PRE>
   BODY3_NUT_PREC_ANGLES  = (  125.045    -1935.5328
                               250.090    -3871.0656
                               260.008   475263.3
                               176.625   487269.6519
                               357.529    35999.04     )
 
   BODY301_POLE_RA        = (  270.000    0.003        0. )
   BODY301_POLE_DEC       = (  +66.541    0.013        0. )
   BODY301_PM             = (   38.317  +13.1763582    0. )
 
   BODY301_NUT_PREC_RA  = (  -3.878  -0.120  +0.070  -0.017   0.    )
   BODY301_NUT_PREC_DEC = (  +1.543  +0.024  -0.028  +0.007   0.    )
   BODY301_NUT_PREC_PM  = (  +3.558  +0.121  -0.064  +0.016  +0.025 )
</PRE>
   Note that there are five nutation precession angles, with two
   coefficients defining each one. The trigonometric terms in the
   expressions for the right ascension, declination, and prime meridian
   location for the moon require five nutation precession angles.
<P>
 
   If a NAIF Toolkit user were to update this model with a new one that
   had, for example, only one nutation precession angle, then the variables
<P>
 
<PRE>
   BODY301_NUT_PREC_RA
   BODY301_NUT_PREC_DEC
   BODY301_NUT_PREC_PM
</PRE>
   would each have to be assigned only one value. Failure to make this
   change would result in an error being signaled at run-time by any CSPICE
   PCK access routine that uses these variables.
<P>
 
<BR><BR>
<A NAME="Binary PCK Kernel Format"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H2> Binary PCK Kernel Format
</H2><HR ALIGN="LEFT" WIDTH=50% ><P><BR><BR>
   The binary PCK file format is built upon the SPICE DAF (Double precision
   Array File) architecture. Readers who are not familiar with this
   architecture are referred to the DAF Required Reading document, <a href="../req/daf.html">daf.req</a>,
   which describes the common aspects of all DAF formats, as well as a
   collection of CSPICE subroutines that support the DAF architecture. The
   SPICE file identification word occupying the first eight bytes of a
   properly created binary PCK file is ``DAF/PCK ''. For more information
   on SPICE identification words refer to the Kernel Required Reading
   document, <a href="../req/kernel.html">kernel.req</a>. Most users will not need to understand the details
   of the structure of binary PCK files.
<P>
 
<BR><BR>
<A NAME="Segments--The Fundamental PCK Building Blocks"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> Segments--The Fundamental PCK Building Blocks
</H3><P><BR><BR>
   A binary PCK file contains one or more `segments'. Each segment contains
   data sufficient to compute the axes of a body-fixed planetary coordinate
   system, relative to a specified inertial reference frame, as a function
   of time.
<P>
 
   The data in each segment are stored as a single array. The summary for
   the array, called a `descriptor', has two double precision components:
<P>
 
<UL>
<TT>1.</TT> The initial epoch of the interval for which data are contained in the
segment, in ephemeris seconds past Julian year 2000;
<BR><BR></UL>
<UL>
<TT>2.</TT> The final epoch of the interval for which data are contained in the
segment, in ephemeris seconds past Julian year 2000.
<BR><BR></UL>
   The descriptor has five integer components:
<P>
 
<UL>
<TT>1.</TT> The NAIF integer code for the body;
<BR><BR></UL>
<UL>
<TT>2.</TT> The NAIF integer code for the inertial reference frame;
<BR><BR></UL>
<UL>
<TT>3.</TT> The integer code for the representation (type of PCK data). Only type 2 is
presently supported;
<BR><BR></UL>
<UL>
<TT>4.</TT> The initial address of the array;
<BR><BR></UL>
<UL>
<TT>5.</TT> The final address of the array.
<BR><BR></UL>
   The name of each array may contain up to 40 characters. This space may
   be used to store a `pedigree' for the data in the array. The pedigree of
   a segment should allow a user to determine the conditions under which
   the data in the segment were generated.
<P>
 
<BR><BR>
<A NAME="The Comment Area"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> The Comment Area
</H3><P><BR><BR>
   Preceding the `segments', the Comment Area provides space in a binary
   PCK file for storing additional textual information besides what is
   written in the array names. Ideally, each binary PCK file would contain
   internal documentation that describes the origin, recommended use, and
   any other pertinent information about the data in that file. For
   example, the beginning and ending epochs for the file, the names and
   NAIF integer codes of the bodies included, an accuracy estimate, the
   date the file was produced, and the names of the source files used in
   making the binary PCK file could be included in the Comment Area.
<P>
 
   CSPICE provides a family of subroutines for handling this Comment Area.
   This software provides the ability to add, extract, read, and delete
   comments and convert commented files from binary format to transfer
   format and back to binary again.
<P>
 
<BR><BR>
<A NAME="Binary PCK Data Types"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> Binary PCK Data Types
</H3><P><BR><BR>
   The third integer component of the descriptor---the code for the
   representation, or `data type'---is the key to the binary PCK format.
   For purposes of determining the segment best suited to fulfill a
   particular request, all segments are treated equally. It is only when
   the data in a segment are to be evaluated that the type of data used to
   represent the data becomes important. Because this step is isolated
   within low-level readers, new data types can be added to the binary PCK
   format without affecting application programs that use the higher level
   readers.
<P>
 
<BR><BR>
<A NAME="Supported Data Types"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> Supported Data Types
</H3><P><BR><BR>
   Two representations, or data types, are currently supported by the
   binary PCK routines in CSPICE. They are Chebyshev polynomials (Euler
   angles only), called "Type 2" and Chebyshev polynomials (Euler angles
   and their derivatives) for intervals of possibly varying lengths, called
   "Type 3".
<P>
 
<BR><BR>
<A NAME="Type 2: Chebyshev (Angles only)"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> Type 2: Chebyshev (Angles only)
</H3><P><BR><BR>
   These are sets of Chebyshev polynomial coefficients for the Euler
   angles, defining as a function of time the right ascension and
   declination of a body's north pole, and the prime meridian rotation. The
   rates of the angles are obtained by differentiation.
<P>
 
   The segments contains an arbitrary number of logical records with each
   record describing a set of Chebyshev coefficients valid across an
   interval of fixed length. The subroutine pcke02_ contains the algorithm
   used to construct a set of Euler angles from a particular record and
   epoch.
<P>
 
   A segment consists of a set of records, ordered by increasing initial
   epoch, each record containing the same number of coefficients. The
   segment structure is illustrated below:
<P>
 
<PRE>
 
           +---------------+
           | Record 1      |
           +---------------+
           | Record 2      |
           +---------------+
             .
             .
             .
           +---------------+
           | Record N      |
           +---------------+
           | INIT          |
           +---------------+
           | INTLEN        |
           +---------------+
           | RSIZE         |
           +---------------+
           | N             |
           +---------------+
 
</PRE>
   A four-number `directory' at the end of the segment contains the
   information needed to determine the location of the record corresponding
   to a particular epoch.
<P>
 
<UL>
<TT>1.</TT> INIT is the initial epoch of the first record, given in ephemeris seconds
past 2000 Jan 01 12:00:00, also known as J2000.
<BR><BR></UL>
<UL>
<TT>2.</TT> INTLEN is the length of the interval covered by each record, in seconds.
<BR><BR></UL>
<UL>
<TT>3.</TT> RSIZE is the total size of (number of array elements in) each record.
<BR><BR></UL>
<UL>
<TT>4.</TT> N is the number of records contained in the segment.
<BR><BR></UL>
   Each record is structured as follows:
<P>
 
<PRE>
 
           +------------------+
           | MID              |
           +------------------+
           | RADIUS           |
           +------------------+
           | X  coefficients  |
           +------------------+
           | Y  coefficients  |
           +------------------+
           | Z  coefficients  |
           +------------------+
 
</PRE>
   The first two elements in the record, MID and RADIUS, are the midpoint
   and radius of the time interval covered by coefficients in the record.
   These are used as parameters to perform transformations between the
   domain of the record (from MID - RADIUS to MID + RADIUS) and the domain
   of Chebyshev polynomials (from -1 to 1 ).
<P>
 
   The same number of coefficients is always used for each component, and
   all records are the same size (RSIZE), so the degree of each polynomial
   is
<P>
 
   ( RSIZE - 2 ) / 3 - 1
<P>
 
<BR><BR>
<A NAME="Type 3: Chebyshev (Angles and derivatives)"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> Type 3: Chebyshev (Angles and derivatives)
</H3><P><BR><BR>
   These are sets of Chebyshev polynomial coefficients for the Euler
   angles, defining right ascension (RA) and declination (DEC) of the
   body's north pole, and its prime meridian rotation (W) as a function of
   time, and their derivatives. This data type was created for the attitude
   of the asteroid Eros.
<P>
 
   Each segment contains an arbitrary number of logical records. Each
   record contains a set of Chebyshev coefficients for angles and
   derivatives valid throughout an interval defined in the record. The
   lengths of these intervals may vary within a segment. The subroutine
   pcke03_ contains the algorithm used to construct a set of Euler angles
   from a particular record and epoch. All records contain the same number
   of coefficients.
<P>
 
   A segment of this type is structured as follows:
<P>
 
<PRE>
 
           +---------------+
           | Record 1      |
           +---------------+
           | Record 2      |
           +---------------+
             .
             .
             .
           +---------------+
           | Record N - 1  |
           +---------------+
           | Record N      |
           +---------------+
</PRE>
   where each record has the following format:
<P>
 
<PRE>
   ---------------------------------------------------
   |  Midpoint of the approximation interval in TDB  |
   ---------------------------------------------------
   | Radius of the approximation interval in seconds |
   ---------------------------------------------------
   |        coefficients for the RA position         |
   ---------------------------------------------------
   |        coefficients for the DEC position        |
   ---------------------------------------------------
   |        coefficients for the W position          |
   ---------------------------------------------------
   |        coefficients for the RA velocity         |
   ---------------------------------------------------
   |        coefficients for the DEC velocity        |
   ---------------------------------------------------
   |        coefficients for the W velocity          |
   ---------------------------------------------------
</PRE>
   TDB is time in ephemeris seconds past J2000, called et in the CSPICE
   system.
<P>
 
<BR><BR>
<A NAME="Creating Binary PCKs"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H2> Creating Binary PCKs
</H2><HR ALIGN="LEFT" WIDTH=50% ><P><BR><BR>
   Only very knowledgeable users who need to incorporate new
   planetary/satellite orientation information in binary format should
   consider writing binary PCK files. Users who write binary PCK files must
   have a thorough understanding of the information they wish to place in a
   binary PCK file. They must also master the high level structure of the
   PCK files, and they must be sure to correctly package the data for the
   PCK writing subroutines provided in CSPICE. We also strongly recommend
   that the writer of a PCK file include descriptive comments in the
   comment area. Normally, binary PCK files should be obtained from NAIF.
<P>
 
   The user should keep in mind that the PCK segments should be as large as
   possible to create smaller, faster to load files.
<P>
 
   The are generally three steps to creating a binary PCK file.
<P>
 
<UL>
<TT>1.</TT> Open the file.
<BR><BR></UL>
<UL>
<TT>2.</TT> Begin the segment, add data to the segment and close the segment.
<BR><BR></UL>
<UL>
<TT>3.</TT> Close the file.
<BR><BR></UL>
   The subroutine pckopn_ is used to open a new binary PCK file. Below is
   an example for a call to pckopn_. ```name''' is the name of the file to
   be opened, ```ifname''' is the internal file name, ```handle''' is the
   handle of the opened SPK file. We use ```i''' for the number of record
   to reserve for comments.
<P>
 
<PRE>
         pckopn_( file, ifname, &amp;i, &amp;handle, file_len, ifname_len)
 
         (file_len is the length of the name string,
          ifname_len is the length of the ifname string )
</PRE>
   The method for beginning the segment, adding data to the segment and
   closing the segment differs with the PCK type.
<P>
 
   For segments of type 2, there is a segment writing routine called
   pckw02_ in CSPICE. This routine takes as input arguments the handle of
   an PCK file that is open for writing, the information needed to
   construct the segment descriptor, and the data to be stored in the
   segment. The header of the subroutine provides a complete description of
   the input arguments and an example of its usage. Here's an example of a
   call to pckw02_:
<P>
 
<PRE>
 
         pckw02_ ( &amp;handle   , &amp;body  , frame  , &amp;first, &amp;last, segid,
                   &amp;intlen   , &amp;n     , &amp;polydg,  cdata, &amp;btime,
                   frame_len, segid_len);
 
</PRE>
   For type 3, there are three subroutines used in creating a binary PCK
   file. They are pck03b_, which begins a type 3 segment, PCK03A, which
   adds data to segment, and pck03e_, which ends a segment. The type 3
   subroutines can be used in a loop, where pck03a_ is called to add data
   to the segment. Here is a code fragment that begins a type 3 segment,
   writes data to that segment in a loop, and then closes the segment.
<P>
 
<PRE>
      pck03b_( &amp;handle, segid    , &amp;body, frame, &amp;first, &amp;last,
               chbdeg , segid_len, frame_len);
 
      do
         {
         ...
         pck03a_ ( &amp;handle, &amp;n, coeffs, epochs);
         ...
         } while ( &lt;a condition&gt; );
 
      pck03e_( &amp;handle);
 
</PRE>
   When a user is finished writing segments to an PCK file, the file must
   be closed with the subroutine pckcls_.
<P>
 
<PRE>
      pckcls_ ( &amp;handle );
</PRE>
<BR><BR>
<A NAME="PCK Software"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H1> PCK Software
</H1><HR SIZE=3 NOSHADE><P><BR><BR><BR>
   This section describes the specifications and proper use of the CSPICE
   PCK software.
<P>
 
<BR><BR>
<A NAME="Getting PCK Data into Your Program"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H2> Getting PCK Data into Your Program
</H2><HR ALIGN="LEFT" WIDTH=50% ><P><BR><BR>
   Because loading PCK files is usually time-consuming, it is good
   programming practice to have applications load PCK files during program
   initialization rather than throughout their main processing thread,
   especially if that processing thread is a loop.
<P>
 
   It is also wise to avoid designing data processing systems that
   effectively place PCK loading in a tight loop by requiring repeated runs
   of programs that expend a significant fraction of their run time on
   loading PCK files. If a program loads PCK files, it is preferable that
   it do all of its processing in a single run, or at least in a small
   number of runs, rather than carry out its processing by being re-run a
   large number of times: the former design will greatly reduce the ratio
   of the time the program spends loading PCKs to the time it spends on the
   rest of its data processing.
<P>
 
<BR><BR>
<A NAME="Loading Text PCK Kernels"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> Loading Text PCK Kernels
</H3><P><BR><BR>
   As earlier mentioned, in order to use text PCK files in an application,
   the data in the files must be read into memory. This is accomplished by
   calling the CSPICE routine <a href="../cspice/furnsh_c.html">furnsh_c</a>. The name of the text PCK file to
   load is supplied as an input to <a href="../cspice/furnsh_c.html">furnsh_c</a>, for example:
<P>
 
<PRE>
   <a href="../cspice/furnsh_c.html">furnsh_c</a> ( "P_CONSTANTS.KER" );
</PRE>
   File names supplied to <a href="../cspice/furnsh_c.html">furnsh_c</a> will generally be system-dependent. It
   is good programming practice to not use hard-coded file names in calls
   to <a href="../cspice/furnsh_c.html">furnsh_c</a>. Instead, applications should obtain kernel file names by
   one of the following methods:
<P>
 
<UL>
<TT>--</TT> Reading the kernel file names from a file containing the names. (This
allows users to change the kernel files without re-compiling and re-linking
the application.)
<BR><BR></UL>
<UL>
<TT>--</TT> Prompting the user for the file names at run-time.
<BR><BR></UL>
   An application can load any number of text PCK files during a single
   program run. There are, however, parameterized limits on both the total
   number of kernel variables that can be stored and on the total number of
   data values assigned to those variables.
<P>
 
   Each time a text PCK is loaded, the assignments made in the file are
   maintained in the PCK software. In particular, if a kernel variable
   occurs in multiple PCKs loaded in a single run of a program, the value
   of the variable will be the one assigned in the following priority: last
   binary PCK file loaded, previously loaded binary PCK files, then last
   loaded text PCK files followed by previously loaded text PCK files. All
   binary PCK files take precedence over text PCK files. Within the binary
   and/or text file groups, the last loaded files takes precedence.
<P>
 
<BR><BR>
<A NAME="Loading Binary PCK Kernels"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> Loading Binary PCK Kernels
</H3><P><BR><BR>
   The routine <a href="../cspice/furnsh_c.html">furnsh_c</a> maintains a database of loaded binary PCK files.
   The calling program indicates which files are to be used by passing
   their names to <a href="../cspice/furnsh_c.html">furnsh_c</a>.
<P>
 
<PRE>
      <a href="../cspice/furnsh_c.html">furnsh_c</a> ( "example.pck" );
</PRE>
   Once an PCK file has been loaded, it may be accessed by the PCK
   software. Each set of constants is computed from a distinct segment.
<P>
 
   A PCK file may contain any number of segments. In fact, the same file
   may contain overlapping segments: segments containing data for the same
   body over a common interval. When this happens, the latest segment in a
   file supersedes any competing segments earlier in the file. Similarly,
   the latest file loaded supersedes any earlier files. In effect, several
   loaded files become equivalent to one large file. Binary PCK files take
   precedence over text PCK files.
<P>
 
<BR><BR>
<A NAME="Unloading Binary PCK Kernels"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> Unloading Binary PCK Kernels
</H3><P><BR><BR>
   It is possible, though unlikely, that a program would need to make use
   of many binary PCK files in the course of a single execution. On the
   other hand, the number of binary PCK files that may be open at any one
   time is limited, so such a program might need to unload some PCK files
   to make room for others. A binary PCK file may be unloaded by supplying
   its name to subroutine <a href="../cspice/unload_c.html">unload_c</a>. The call to this subroutine is shown
   below,
<P>
 
<PRE>
      <a href="../cspice/unload_c.html">unload_c</a> ( filename );     { Unload binary PCK file }
</PRE>
<BR><BR>
<A NAME="Binary PCK Coverage Summary Routines"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H2> Binary PCK Coverage Summary Routines
</H2><HR ALIGN="LEFT" WIDTH=50% ><P><BR><BR>
   The CSPICE includes two functions for obtaining information about the
   contents of a binary PCK file from within an application.
<P>
 
   The <a href="../cspice/pckfrm_c.html">pckfrm_c</a> function provides an API via which an application can find
   the set of reference frames for which a specified binary PCK file
   contains data. The reference frame class ID codes are returned in a
   SPICE ``set'' data structure (see <a href="../req/sets.html">sets.req</a>).
<P>
 
   The <a href="../cspice/pckcov_c.html">pckcov_c</a> function provides an API via which an application can find
   the time periods for which a specified binary PCK file provides data for
   a reference frame of interest. The coverage information is a set of
   disjoint time intervals returned in a SPICE ``window'' data structure
   (see <a href="../req/windows.html">windows.req</a>).
<P>
 
   Refer to the headers of <a href="../cspice/pckfrm_c.html">pckfrm_c</a> and <a href="../cspice/pckcov_c.html">pckcov_c</a> for details on the use of
   those routines.
<P>
 
<BR><BR>
<A NAME="Access Routines"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H2> Access Routines
</H2><HR ALIGN="LEFT" WIDTH=50% ><P><BR><BR>
   CSPICE contains two basic categories of PCK access routines: those that
   return PCK data directly, and those that return quantities derived from
   PCK data. This section discusses the PCK access routines in the later
   category: these routines deal with coordinate and state transformations.
<P>
 
   All of the routines listed here make use of the orientation models
   discussed in the section titled ``Orientation Models used by PCK
   Software.'' Note that in order to use these routines, an application
   must first load a PCK file (or files) containing sufficient data to
   define all of the required orientation models. If needed data has not
   been loaded, these routines will signal run-time errors when called.
<P>
 
<BR><BR>
<A NAME="High-Level PCK Data Access"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> High-Level PCK Data Access
</H3><P><BR><BR>
   To obtain the matrix that transforms 3-vectors from a specified
   reference frame to another frame, at a specified ephemeris time, use the
   routine <a href="../cspice/pxform_c.html">pxform_c</a>. The calling sequence is
<P>
 
<PRE>
   <a href="../cspice/pxform_c.html">pxform_c</a> ( from, to,  et,  rotate );
</PRE>
   In the argument list for <a href="../cspice/pxform_c.html">pxform_c</a>:
<P>
 
<DL><DT>
<B>
 `from'
</B><BR><BR>
<DD>
 is the name of a reference frame in which a position vector is known.<BR>
</DL>
<DL><DT>
<B>
 `to'
</B><BR><BR>
<DD>
 is the name of a reference frame in which it is desired to represent a
position vector.<BR>
</DL>
<DL><DT>
<B>
 `et'
</B><BR><BR>
<DD>
 is the epoch in ephemeris seconds past the epoch of J2000 (TDB) at
which the position transformation matrix `rotate' should be evaluated.<BR>
</DL>
<DL><DT>
<B>
 `rotate'
</B><BR><BR>
<DD>
 is the matrix that transforms position vectors from the reference frame
`from' to the frame `to' at epoch `et'.<BR>
</DL>
   For example, let V50 be a vector specified relative to the B1950
   inertial reference frame. The call
<P>
 
<PRE>
   <a href="../cspice/pxform_c.html">pxform_c</a>( "B1950", "IAU_EARTH", &amp;et, rotate );
</PRE>
   returns a matrix ```rotate''' such that left-multiplying V50 by
   ```rotate''' --- accomplished in CSPICE by the call
<P>
 
<PRE>
   <a href="../cspice/mxm_c.html">mxm_c</a> ( rotate, v50, vbodfx );
</PRE>
   will return the vector ```vbodfx''' specified relative to the Earth's
   (``body-fixed'') planetocentric frame at time ```et'''.
<P>
 
   Note that many practical applications of <a href="../cspice/pxform_c.html">pxform_c</a> require that a
   light-time corrected value of et be supplied as an input. See
   ``Computing the Sub-Observer Point'' in the ``Examples'' section below.
<P>
 
   The fundamental quantities defined by PCK orientation models are
   actually Euler angles, not matrices. These Euler angles, which we call
   ``RA, DEC, and W,'' are related to the matrix ```rotate''' shown above
   by the equation
<P>
 
<PRE>
   rotate = [ W ]   [ Pi/2 - DEC ]   [ Pi/2 + RA ]
               3                1               3
 
</PRE>
   The units of these angles are radians. To directly retrieve these
   angles, use the call
<P>
 
<PRE>
   bodeul_ ( &amp;body, &amp;et, &amp;ra, &amp;dec, &amp;w, &amp;lambda );
</PRE>
<DL><DT>
<B>
 `body'
</B><BR><BR>
<DD>
 is the NAIF integer code of the body defining the planetocentric
coordinate system.<BR>
</DL>
<DL><DT>
<B>
 `et'
</B><BR><BR>
<DD>
 is the ephemeris time at which the orientation model given the basis
vectors of the planetocentric frame is to be evaluated.<BR>
</DL>
<DL><DT>
<B>
 `ra' and `dec'
</B><BR><BR>
<DD>
 represent the right ascension and declination of the North pole of body
at et with respect to the J2000 inertial reference frame.<BR>
</DL>
<DL><DT>
<B>
 `w'
</B><BR><BR>
<DD>
 is the prime meridian location for ```body''' at ```et''', also
measured with respect to the J2000 inertial reference frame.<BR>
</DL>
<DL><DT>
<B>
 `lambda'
</B><BR><BR>
<DD>
 is the positive west longitude, measured from the prime meridian of
body, of the longest axis of the triaxial ellipsoidal model for body
given in a PCK file.<BR>
</DL>
   Currently, the only body having a non-zero value of LAMBDA is Mars (see
   [195]). CSPICE software does not currently make use of ```lambda'''.
<P>
 
   CSPICE provides a routine analogous to <a href="../cspice/pxform_c.html">pxform_c</a> that returns the matrix
   to transform state vectors between reference frames. This routine is
   called <a href="../cspice/sxform_c.html">sxform_c</a>; the calling sequence being
<P>
 
<PRE>
   <a href="../cspice/sxform_c.html">sxform_c</a> ( from, to,  et,  xform );
</PRE>
   The input arguments ```from''', ```to''', and ```et''' have the same
   meanings as in the argument list of <a href="../cspice/pxform_c.html">pxform_c</a>. The output argument
   ```xform''' is the 6x6 matrix required to transform state vectors from
   inertial to body-fixed coordinates. Left multiplication of a state
   vector by ``XFORM'' will transform it from the frame specified by
   ```from''' to the frame specified by ```to''' at time ```et'''.
<P>
 
<BR><BR>
<A NAME="Low-Level PCK Data Access"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> Low-Level PCK Data Access
</H3><P><BR><BR>
   WARNING: These low-level access routines for text PCK files only search
   the text kernel pool for these values. Values found in loaded binary PCK
   files will NOT be found by these routines. The values retrieved from a
   binary PCK file take precedence over the values found in the text PCK
   kernels. Therefore, if binary kernels have been loaded, values returned
   by these low level routines may not be the same values used by higher
   level routines like <a href="../cspice/sxform_c.html">sxform_c</a> and <a href="../cspice/pxform_c.html">pxform_c</a>. We recommend the user who
   loads binary PCKs NOT USE these low-level routines!
<P>
 
   The lowest-level CSPICE PCK access routines are <a href="../cspice/gipool_c.html">gipool_c</a>, <a href="../cspice/gdpool_c.html">gdpool_c</a> and
   <a href="../cspice/gcpool_c.html">gcpool_c</a>. These are general-purpose routines for retrieving any text
   kernel data by data type (integer, double precision, and character
   string, respectively) loaded via <a href="../cspice/furnsh_c.html">furnsh_c</a>. The calling sequences for the
   routines:
<P>
 
<PRE>
   <a href="../cspice/gcpool_c.html">gcpool_c</a> ( name, start, room, lenout, &amp;n, vals, &amp;found );
   <a href="../cspice/gdpool_c.html">gdpool_c</a> ( name, start, room, &amp;n, vals, &amp;found );
   <a href="../cspice/gipool_c.html">gipool_c</a> ( name, start, room, &amp;n, vals, &amp;found );
</PRE>
   The meanings of the arguments are follows:
<P>
 
<DL><DT>
<B>
 `name'
</B><BR><BR>
<DD>
 is the name of the kernel variable whose values are desired. This is
the name used in a PCK file to make an assignment.<BR>
</DL>
<DL><DT>
<B>
 `start'
</B><BR><BR>
<DD>
 is the index of the first component of NAME to return. If `start' is
less than 1, it will be treated as 1.<BR>
</DL>
<DL><DT>
<B>
 `room'
</B><BR><BR>
<DD>
 is the maximum number of components that should be returned for this
variable.<BR>
</DL>
<DL><DT>
<B>
 `lenout'
</B><BR><BR>
<DD>
 is the allowed length of the output string. This length must be large
enough to hold the output string plus the terminator.<BR>
</DL>
<DL><DT>
<B>
 `n'
</B><BR><BR>
<DD>
 is the number of data values assigned to the kernel variable.<BR>
</DL>
<DL><DT>
<B>
 `vals'
</B><BR><BR>
<DD>
 is the return arrays of sufficient size and correct type to contain the
data corresponding to `name'.<BR>
</DL>
<DL><DT>
<B>
 `found'
</B><BR><BR>
<DD>
 is a logical flag indicating whether the kernel variable designated by
name was actually loaded.<BR>
</DL>
   The <a href="../cspice/gipool_c.html">gipool_c</a>, <a href="../cspice/gdpool_c.html">gdpool_c</a>, and <a href="../cspice/gcpool_c.html">gcpool_c</a> set is frequently used by other
   CSPICE routines; however, CSPICE users will usually find it more
   convenient to use the PCK access routines <a href="../cspice/bodvrd_c.html">bodvrd_c</a> or <a href="../cspice/bodvcd_c.html">bodvcd_c</a>, routines
   that return double precision body constants, e.g radius, RA/DEC of the
   spin axis, the GM value, etc.
<P>
 
   In text PCK's produced by NAIF, PCK variables will have names conforming
   to the naming convention used in CSPICE, that is, the kernel variable
   names have the form
<P>
 
<PRE>
   BODYnnn_&lt;item name&gt;
</PRE>
   <a href="../cspice/bodvrd_c.html">bodvrd_c</a> and <a href="../cspice/bodvcd_c.html">bodvcd_c</a> retrieve the values of such variables from the
   kernel pool; <a href="../cspice/bodvrd_c.html">bodvrd_c</a> accepts as inputs the body name and a string
   making up the portion of the item's name following the prefix:
<P>
 
<PRE>
   <a href="../cspice/bodvrd_c.html">bodvrd_c</a> ( bodynm, item, maxn, &amp;dim, values );
</PRE>
   <a href="../cspice/bodvcd_c.html">bodvcd_c</a> functions in the same manner as <a href="../cspice/bodvrd_c.html">bodvrd_c</a> except bodvcd_c
   accepts as inputs the body NAIF ID and the item string, ```item''', as
   described for <a href="../cspice/bodvrd_c.html">bodvrd_c</a>:
<P>
 
<PRE>
   <a href="../cspice/bodvcd_c.html">bodvcd_c</a> ( bodyid, item, maxn, &amp;dim, values );
</PRE>
   For example, to obtain the radii of the of Earth, a program could use
   either the call
<P>
 
<PRE>
   <a href="../cspice/bodvrd_c.html">bodvrd_c</a> ( "EARTH", "RADII", 3 &amp;dim, values );
</PRE>
   or the call
<P>
 
<PRE>
   <a href="../cspice/bodvcd_c.html">bodvcd_c</a> ( 399, "RADII", 3 &amp;dim, values );
</PRE>
   Both calls return the dimension and values associated with the variable
<P>
 
<PRE>
   BODY399_RADII
</PRE>
   namely
<P>
 
<PRE>
   dim     = 3;
   value[0] = 6378.140;
   value[1] = 6378.140;
   value[2] = 6356.755;
</PRE>
   It is possible to test whether a kernel variable has been loaded by
   calling the CSPICE logical function <a href="../cspice/bodfnd_c.html">bodfnd_c</a>, as long as the variables
   in question follow the CSPICE naming convention. The calling sequence is
<P>
 
<PRE>
   found = <a href="../cspice/bodfnd_c.html">bodfnd_c</a> ( body, item );
</PRE>
   where body is the NAIF integer code of the body, and ```item''' is the
   string making up the portion of the item's name following the prefix
<P>
 
<PRE>
   BODYnnn_
</PRE>
   For example, to test whether values for Jupiter's radii have been
   loaded, the test
<P>
 
<PRE>
   found = <a href="../cspice/bodfnd_c.html">bodfnd_c</a> ( 599, "RADII" )
</PRE>
   could be used. The variable ```found''' would be returned as SPICETRUE
   if a PCK file had been loaded containing an assignment of the variable
<P>
 
<PRE>
   BODY599_RADII
</PRE>
<BR><BR>
<A NAME="Examples"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H2> Examples
</H2><HR ALIGN="LEFT" WIDTH=50% ><P><BR><BR>
   This section illustrates some typical applications of CSPICE PCK
   software.
<P>
 
<BR><BR>
<A NAME="Transforming a body-fixed state to the inertial J2000 frame"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H3> Transforming a body-fixed state to the inertial J2000 frame
</H3><P><BR><BR>
   Occasionally, it may be useful to transform a state vector known in
   body-fixed coordinates to inertial J2000. To perform the transformation
   correctly, it is necessary to take into account the time derivative of
   the inertial-to-body-fixed coordinate transformation. A discussion of
   the error made by ignoring this derivative term is given in [214].
<P>
 
   The following code fragment shows how to use the CSPICE routine <a href="../cspice/sxform_c.html">sxform_c</a>
   to transform state vectors between coordinate frames.
<P>
 
   The 6-vector ```state''' represents the body-fixed state (position and
   velocity) of an object with respect to the center of the body at time
   ```et'''. The matrix ```xform''' is declared as a 6x6 double-precision
   matrix.
<P>
 
   This program loads both a text and a binary PCK file. The question of
   from which file is the data retrieved is answered by the coverage of the
   files. If a particular requested time and body is covered by the loaded
   binary file, the binary data will be used. If not, the text data will be
   used.
<P>
 
   In this example, we present a small program that solves a realistic
   geometry problem: transform an earth station location given geodetic
   coordinates to the corresponding state vector in the J2000 reference
   frame.
<P>
 
<PRE>
 
   #include "SpiceUsr.h"
   #include &lt;stdlib.h&gt;
 
   SpiceDouble     lon;
   SpiceDouble     lat;
   SpiceDouble     alt;
   SpiceDouble     f;
   SpiceDouble     equatr;
   SpiceDouble     polar;
   SpiceDouble     et;
   SpiceDouble     abc[3];
   SpiceDouble     pos[3];
   SpiceDouble     jstate[6];
   SpiceDouble     xform[6][6];
   SpiceDouble     state[] = { 0., 0., 0.,
                               0., 0., 0. };
 
   SpiceInt        dim;
   SpiceInt        i;
 
   int main()
      {
 
      /*
 
      Suppose you have geodetic coordinates of a station on the
      surface of Earth and that you need the inertial (J2000)
      state of this station.  The following code fragment
      illustrates how to transform the geodetic state of the
      station to a J2000 state.
 
      Load the SPK, PCK and LSK kernels.
 
      */
      <a href="../cspice/furnsh_c.html">furnsh_c</a>( "/kernels/gen/lsk/naif0008.tls");
      <a href="../cspice/furnsh_c.html">furnsh_c</a>( "/kernels/gen/pck/pck00008.tpc");
      <a href="../cspice/furnsh_c.html">furnsh_c</a>( "/kernels/gen/spk/de405_2000-2050.bsp");
 
      /*
      Also load a high precision earth orientation kernel. This
      returns orientation to milli-second accuracy.
      */
      <a href="../cspice/furnsh_c.html">furnsh_c</a>( "/kernels/gen/pck/earth_000101_050509_050215.bpc");
 
      /*
      Define a geodetic longitude, latitude, altitude
      coordinate set. These coordinates are defined in the
      non-inertial, earth fixed frame "IAU_EARTH".
      */
      lon = 118.25 * <a href="../cspice/rpd_c.html">rpd_c</a>();
      lat = 34.05  * <a href="../cspice/rpd_c.html">rpd_c</a>();
      alt = 0.;
 
      /*
      Define a UTC time of interest. Convert the 'utc' string
      to ephemeris time J2000.
      */
      <a href="../cspice/str2et_c.html">str2et_c</a>( "March 1, 2005", &amp;et);
 
      /*
      Retrieve the equatorial and polar axis of the earth.
      */
      <a href="../cspice/bodvrd_c.html">bodvrd_c</a>( "EARTH", "RADII", 3, &amp;dim, abc );
      equatr =  abc[0];
      polar  =  abc[2];
 
      /*
      Calculate the flattening factor for earth.
      */
      f =  ( equatr - polar  ) / equatr;
 
      /*
      Calculate the Cartesian coordinates on earth
      in the ITRF93 frame for the location at
      'lon', 'lat', 'alt'.
      */
      <a href="../cspice/georec_c.html">georec_c</a>( lon, lat, alt, equatr, f, pos );
 
      /*
      <a href="../cspice/georec_c.html">georec_c</a> returned the position vector of the geodetic
      coordinates, but we want the state vector. Since it is a fixed
      location on the earth referenced in the high precision
      "ITRF93" frame, the location has no velocity in that frame.
      We need to extend 'pos' to a 6-vector, the final three elements
      with value 0. Copy 'pos' to the first
      three elements of 'state'.
      */
      state[0] = pos[0];
      state[1] = pos[1];
      state[2] = pos[2];
 
      /*
      Retrieve the transformation matrix from "ITRF93"
      to "J2000" at epoch 'et'.
      */
      <a href="../cspice/sxform_c.html">sxform_c</a>( "ITRF93", "J2000", et, xform );
 
      /*
      Transform the Cartesian state vector from "IAU_EARTH"
      to "J2000."
      */
      <a href="../cspice/mxvg_c.html">mxvg_c</a>( xform, state, 6,6, jstate );
 
      /*
      Write out the results.
      */
      for( i=0; i&lt;6; i++ )
         {
         printf( " %24.8f\n", jstate[i] );
         }
 
      /*
      It's always good form to unload kernels after use.
      */
      <a href="../cspice/unload_c.html">unload_c</a>( "standard.ker" );
 
      return 0;
      }
 
</PRE>
<BR><BR>
<A NAME="Creating a binary PCK file, type 03."></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H2> Creating a binary PCK file, type 03.
</H2><HR ALIGN="LEFT" WIDTH=50% ><P><BR><BR>
   We assume that we are creating a new file for this example. In addition,
   we will make use of the fictitious subroutine GENREC to generate a type
   03 PCK data record. This is for demonstrative purposes only, and is not
   intended to be a complete program.
<P>
 
   The following routines will be used in this example:
<P>
 
<UL>
<TT>--</TT> pckcls_ -- Close a PCK file.
<BR><BR></UL>
<UL>
<TT>--</TT> pckopn_ -- Open a new PCK file.
<BR><BR></UL>
<UL>
<TT>--</TT> pck03b_ -- Begin a type 03 PCK segment.
<BR><BR></UL>
<UL>
<TT>--</TT> pck03a_ -- Add data to a type 03 PCK segment.
<BR><BR></UL>
<UL>
<TT>--</TT> pck03e_ -- End a type 03 PCK segment.
<BR><BR></UL>
   For the complete details of these routines, please see the appropriate
   source code files.
<P>
 
   Variable declarations for the example code fragment.
<P>
 
<PRE>
      SpiceChar       *  filename;
      SpiceChar       *  ifname;
      SpiceChar       *  frame;
      SpiceChar       *  segid;
 
      SpiceDouble        et;
      SpiceDouble        etstrt;
      SpiceDouble        etstop;
      SpiceDouble     *  record;
      SpiceDouble        step;
 
      SpiceInt           body;
      SpiceInt           chbdeg;
      SpiceInt           handle;
</PRE>
<PRE>
      /*
      THIS IS A CODE FRAGMENT, NOT A PROGRAM!
 
      Assign the name of the file to be created.
      */
 
      filename   = "new_pck.bpc";
 
      /*  Assign an internal filename for the file. */
 
      ifname     = "THIS IS A NEW PCK filename";
 
 
      /* Open the PCK file. */
 
      pckopn_( filename, ifname, 0L, &amp;handle, strlen(filename),
                                             strlen(ifname)   );
 
      /*
      Set the identifier for the segment. This is a character
      string of at most 40 printing ASCII characters. It may
      be blank.
      */
 
      SEGID = "This is a test."
 
      /*
      Set the body for the PCK segment. We will use the
      Moon, ID code 301.
      */
 
      body   = 301;
 
 
      /* We will use the J2000 reference frame for the segment. */
 
      *frame = "J2000";
 
      /*
      Set the degree of the Chebyshev polynomials used for the
      segment.
      */
 
      chbdeg = 10;
 
 
      /* Begin the PCK segment. */
 
      pck03b_( &amp;handle, segid, &amp;body, frame, &amp;etstrt, &amp;etstop, chbdeg,
               strlen(segid), strlen(frame_len) );
 
      /*
      We have a start time and a stop time available, etstrt
      and etstop, and we want to generate records for
      sub-intervals of the interval (etstrt, etstop). For
      simplicity, we will assume equal width intervals and
      that (etstop-etstrt)/step is a positive integer. The
      times are in et, ephemeris seconds past J2000.
      */
 
 
      /* The time step will be one day, 86400 seconds. */
 
      step = 86400.0;
 
 
      /* Set the initial time. */
 
      et  = etstrt;
 
 
      /*
      Loop until we have processed all of the time intervals,
      i.e., when et &gt;= etstop.
      */
 
      do
         {
 
         /*
         Get a type 03 PCK record for the interval et,
         et+step (getrec is not a CSPICE routine).
         */
 
         getrec ( et, et+step, record );
 
 
         /* Add the record to the segment. */
 
         pck03a_ ( &amp;handle, 1L, record, &amp;et );
 
 
         /* Increment the time interval. */
 
         et = et + step;
 
         } while ( et &gt;= etstop );
 
 
 
      /* End the segment. */
 
      pck03e_ ( &amp;handle );
 
 
      /* Close the PCK file. */
 
      pckcls_ ( &amp;handle );
 
</PRE>
<BR><BR>
<A NAME="Summary of Calling Sequences"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H2> Summary of Calling Sequences
</H2><HR ALIGN="LEFT" WIDTH=50% ><P><BR><BR>
   Loading files:
<P>
 
<PRE>
   <a href="../cspice/furnsh_c.html">furnsh_c</a> ( filename );   for text and binary PCKs
</PRE>
   Unloading binary PCK files:
<P>
 
<PRE>
   <a href="../cspice/unload_c.html">unload_c</a> ( filename );   for text or binary PCKs
</PRE>
   Getting binary PCK coverage summary:
<P>
 
<PRE>
   <a href="../cspice/pckfrm_c.html">pckfrm_c</a> ( filename, ids )
   <a href="../cspice/pckcov_c.html">pckcov_c</a> ( filename, idcode, cover  )
</PRE>
   Searching binary PCK files for appropriate information:
<P>
 
<PRE>
   pcksfs_ ( &amp;body, &amp;et, &amp;handle, &amp;descr, ident, &amp;found, ident_len);
</PRE>
   Testing for the presence of variables in the text kernel pool:
<P>
 
<PRE>
   <a href="../cspice/bodfnd_c.html">bodfnd_c</a> ( body, item );
</PRE>
   Obtaining values assigned variables from the text kernel pool:
<P>
 
<PRE>
   <a href="../cspice/bodvrd_c.html">bodvrd_c</a> ( bodynm, item, maxn, &amp;dim, values );
   <a href="../cspice/bodvcd_c.html">bodvcd_c</a> ( bodyid, item, maxn, &amp;dim, values );
 
   <a href="../cspice/gcpool_c.html">gcpool_c</a> ( name, start, room, lenout, &amp;n, vals, &amp;found );
   <a href="../cspice/gdpool_c.html">gdpool_c</a> ( name, start, room, &amp;n, vals, &amp;found );
   <a href="../cspice/gipool_c.html">gipool_c</a> ( name, start, room, &amp;n, vals, &amp;found );
</PRE>
   Obtaining Euler angles and their derivatives from a binary PCK file:
<P>
 
<PRE>
   pckeul_ ( &amp;body, &amp;et, &amp;found, ref, eulang, ref_len);
</PRE>
   Obtaining position transformation matrices between reference frames:
<P>
 
<PRE>
   <a href="../cspice/pxform_c.html">pxform_c</a> ( from, to,  et,  rotate );
</PRE>
   Obtaining Euler angles defining inertial-to-body-fixed coordinate
   transformations:
<P>
 
<PRE>
   bodeul_ ( &amp;body, &amp;et, &amp;ra, &amp;dec, &amp;w, &amp;lambda );
</PRE>
   Obtaining state transformation matrices between reference frames:
<P>
 
<PRE>
   <a href="../cspice/sxform_c.html">sxform_c</a> ( from, to, et, rotate )
</PRE>
   Opening a binary PCK file for writing:
<P>
 
<PRE>
   pckopn_( file, ifname, &amp;ncomch, &amp;handle, file_len, ifname_len)
</PRE>
   Writing type 2 segment to a binary PCK file:
<P>
 
<PRE>
   pckw02_ ( &amp;handle   , &amp;body, frame  , &amp;first, &amp;last , segid,
             &amp;intlen   , &amp;n   , &amp;polydg,  cdata, &amp;btime,
             frame_len, segid_len);
</PRE>
   Writing type 3 segment to a binary PCK file:
<P>
 
<PRE>
   To begin a type 3 segment:
   pck03b_ ( &amp;handle  , segid, &amp;body, frame, &amp;first, &amp;last, &amp;chbdeg,
             segid_len, frame_len);
 
   To add data to a type 3 segment:
   pck03a_( &amp;handle, &amp;nrecs, recrds, epochs);
 
   To end a type 3 segment:
   pck03e_ ( &amp;handle);
</PRE>
   Close a binary PCK file after writing:
<P>
 
<PRE>
   pckcls_ ( &amp;handle );
</PRE>
   Reading a type 2 segment from a binary PCK file:
<P>
 
<PRE>
   pckr02_ ( &amp;handle, descr, &amp;et, record);
</PRE>
   Evaluating a type 2 segment from a binary PCK file:
<P>
 
<PRE>
   pcke02_ ( &amp;et, record, eulang);
</PRE>
   Reading a type 3 segment from a binary PCK file:
<P>
 
<PRE>
   pckr03_  ( &amp;handle, descr, &amp;et, record );
</PRE>
   Evaluating a type 3 segment from a binary PCK file:
<P>
 
<PRE>
   pcke03_ ( &amp;et, record, rotmat);
</PRE>
<BR><BR>
<A NAME="Appendix A: Sample Text PCK file"></A>
<p align="right"><a href="#top"><small>Top</small></a></p>
<H1> Appendix A: Sample Text PCK file
</H1><HR SIZE=3 NOSHADE><P><BR><BR><BR>
   The file shown here is an example of a text PCK file. This file is
   intended only for use as an example; it should not be used as a source
   of data.
<P>
 
<PRE>
 
   P_constants (PcK) SPICE kernel file
   ===================================================================
 
   Update by: Karen Zukor (NAIF)    1994 March 30
 
        First draft of a PCK with internal labels included.
        NOTE: some of the label keywords, values, syntax and overall
        organization are likely to change. Do not write any code that
        uses the above labels.
 
 
   Organization
   --------------------------------------------------------
 
        The sections of this file are as follows.
 
        Introductory Information:
 
            --   Version description
 
            --   Disclaimer
 
            --   Sources
 
            --   Explanation of the PcK contents
 
            --   Body numbers and names
 
        Pck Data:
 
            --   Orientation constants for the Sun and planets
 
            --   Orientation constants for satellites
 
            --   Radii for all bodies
 
 
   Version description
   --------------------------------------------------------
 
        This is a prototype PcK, for use in SPICE training and
        constants evaluation only.
 
        This file is based on the 1991 IAU report,
        NAIF document [306].
 
 
   Disclaimer
   --------------------------------------------------------
 
        This constants file may not contain the parameter values that
        you prefer. Note that this file may be readily modified by
        you or anyone else. NAIF suggests that you inspect this file
        visually before proceeding with any critical or extended data
        processing.
 
        NAIF requests that you update the `by line' and date if
        you modify the file.
 
 
   Sources
   --------------------------------------------------------
 
        The sources for the constants listed in this file are:
 
            1.   ``Report of the IAU/IAG/COSPAR Working Group on
                 Cartographic Coordinates and Rotational Elements of
                 the Planets and Satellites: 1991,'' March 3, 1992.
 
            2.   ``The Astronomical Almanac,'' 1990.
 
            3.   ``Planetary Geodetic Control Using Satellite
                 Imaging,'' Journal of Geophysical Research, Vol. 84,
                 No. B3, March 10, 1979, by Thomas C. Duxbury. This
                 paper is cataloged as NAIF document 190.0.
 
            4.   Letter from Thomas C. Duxbury to Dr. Ephraim
                 Lazeryevich Akim, Keldish Institute of Applied
                 Mathematics, USSR Academy of Sciences, Moscow,
                 USSR. This letter is catalogued as NAIF document
                 number 195.0.
 
            5.   Mars Observer Planetary Constants and Models,
                 November 1990, Mars Observer Document No. 642-321,
                 JPL Document No. D-3444.
 
        Most values are from [1], and these are generally taken from
        [1].  All exceptions are commented where they occur in this
        file. The exceptions are:
 
            --   The second nutation precession angle (M2) for Mars is
                 represented by a quadratic polynomial in the 1991
                 IAU report.   The SPICE subroutine BODEUL can not
                 handle this term (which is extremely small), so we
                 truncate the polynomial to a linear one.
 
            --   The expression for the prime meridian of Deimos (
                 body 402 ) includes a cosine term, which BODEUL
                 doesn't yet handle. The amplitude of the term is
                 0.19 degrees. We simply ignore this term.
 
 
 
   Body numbers and names
   (Contains only information pertinent to Mars Observer)
   ----------------------------------------------------------
 
      Barycenters:
 
           3  Earth barycenter
           4  Mars barycenter
 
           While not relevant to the P_constants kernel, we note here
           for completeness that 0 is used to represent the solar
           system barycenter.
 
 
      Mass centers:
 
           399 Earth
 
           401 Phobos
           402 Deimos
           499 Mars
 
           10  Sun
 
 
   Orientation constants for the Sun and planets
   --------------------------------------------------------
 
 
   Sun
 
           \begindata
 
           BODY10_POLE_RA         = (  286.13       0.          0. )
           BODY10_POLE_DEC        = (   63.87       0.          0. )
           BODY10_PM              = (   84.10     +14.18440     0. )
           BODY10_LONG_AXIS       = (    0.                        )
 
 
           \begintext
 
   Earth
 
           \begindata
 
           BODY399_POLE_RA        = (    0.      -0.641         0. )
           BODY399_POLE_DEC       = (  +90.      -0.557         0. )
           BODY399_PM             = (  190.16  +360.9856235     0. )
           BODY399_LONG_AXIS      = (    0.                        )
 
           \begintext
 
           The linear terms before and after scaling:
 
              -.052992   --&gt;     -1935.5328
              -.105984   --&gt;     -3871.0656
            -13.012      --&gt;   -475263.3
             13.340716   --&gt;   +487269.6519
              -.9856     --&gt;    -35999.04
 
           \begindata
 
           BODY3_NUT_PREC_ANGLES  = (  125.045    -1935.5328
                                       250.090    -3871.0656
                                       260.008   475263.3
                                       176.625   487269.6519
                                       357.529    35999.04     )
 
 
           \begintext
 
   Mars
 
 
           \begindata
 
           BODY499_POLE_RA          = (  317.681     -0.108       0. )
           BODY499_POLE_DEC         = (  +52.886     -0.061       0. )
           BODY499_PM               = (  176.868   +350.8919830   0. )
 
           \begintext
 
        Source [3] specifies the following value for the lambda_a
        term ( BODY4_LONG_AXIS ) for Mars.
 
        This term is the POSITIVE WEST LONGITUDE, measured from the
        prime meridian, of the longest axis of the ellipsoid
        representing the `mean planet surface', as the article states.
 
              body499_long_axis        = (  110.  )
 
        Source [4] specifies the lambda_a value
 
              body499_long_axis        = (  104.9194  )
 
        We list these lambda_a values for completeness. [5] gives
        equal values for both equatorial radii, so the lambda_a
        offset does not apply.
 
        The 1991 IAU report defines M2, the second nutation
        precession angle, by:
 
                                                   2
           192.93  +  1128.4096700 d  +  8.864 T
 
        We truncate the M2 series to a linear expression.
 
        Again, the linear terms are scaled by 36525.0:
 
            -0.4357640000000000      --&gt;     -15916.28010000000
              1128.409670000000      --&gt;   41215163.19675000
            -1.8151000000000000E-02  --&gt;       -662.9652750000000
 
           \begindata
           BODY4_NUT_PREC_ANGLES  = (  169.51     -15916.2801
                                       192.93  +41215163.19675
                                        53.47       -662.965275  )
 
 
 
           \begintext
 
 
   Orientation constants for the satellites
   --------------------------------------------------------
 
 
   Satellites of Mars
 
        Phobos:
 
        The quadratic prime meridian term is scaled by 1/36525**2:
 
           8.864000000000000   ---&gt;   6.6443009930565219E-09
 
           \begindata
 
 
           BODY401_POLE_RA      = (317.68    -0.108     0.           )
           BODY401_POLE_DEC     = (+52.90    -0.061     0.           )
           BODY401_PM           = ( 35.06 +1128.8445850 8.864        )
           BODY401_LONG_AXIS    = (  0.                              )
 
           BODY401_NUT_PREC_RA  = ( +1.79   0.    0.  )
           BODY401_NUT_PREC_DEC = ( -1.08   0.    0.  )
           BODY401_NUT_PREC_PM  = ( -1.42  -0.78  0.  )
 
 
           \begintext
 
        Deimos:
 
        There's a new wrinkle in the Deimos prime meridian
        expression, which is:
                                                     2
              W = 79.41  +  285.1618970 d  -  0.520 T  -  2.58 sin M
                                                                    3
 
                                                       +  0.19 cos M .
                                                                    3
 
                                                              ^
                                                        (new wrinkle)
 
 
        At the present time, the constants kernel software (the
        routine bodeul_ in particular) cannot handle the cosine term;
        we omit this term for the time being. The maximum error we
        can make is 0.19 degrees.
 
        The quadratic prime meridian term is scaled by 1/36525**2:
 
            -0.5200000000000000  ---&gt;   -3.8978300049519307E-10
 
           \begindata
 
           BODY402_POLE_RA      = (316.65   -0.108      0.           )
           BODY402_POLE_DEC     = (+53.52   -0.061      0.           )
           BODY402_PM           = ( 79.41 +285.1618970 -3.897830D-10 )
           BODY402_LONG_AXIS    = (  0.                              )
 
           BODY402_NUT_PREC_RA  = (  0.   0.   +2.98  )
           BODY402_NUT_PREC_DEC = (  0.   0.   -1.78  )
           BODY402_NUT_PREC_PM  = (  0.   0.   -2.58  )
 
 
           \begintext
 
 
   Radii of bodies
   --------------------------------------------------------
 
 
   Sun
 
        Value for the Sun is from the 1990 Almanac (page K7).
 
           \begindata
 
           BODY10_RADII      = (   696000.   696000.   696000.   )
 
           \begintext
 
 
   Earth
 
        Values for the Earth are unchanged in the 1991 IAU report.
 
           \begindata
 
           BODY399_RADII     = (   6378.140   6378.140    6356.75   )
 
           \begintext
 
 
   Mars
 
 
        Current values taken from [5]:
 
           \begindata
 
           BODY499_RADII       = (   3393.4     3393.4     3375.7   )
 
           \begintext
 
 
 
   Satellites of Mars
 
 
           \begindata
 
           BODY401_RADII     = (       13.4        11.2        9.2   )
           BODY402_RADII     = (        7.5         6.1        5.2   )
 
</PRE>

</TD>
</TR>
</TBODY>
</TABLE>

</BODY>

</HTML>
